home *** CD-ROM | disk | FTP | other *** search
/ Shareware Overload Trio 2 / Shareware Overload Trio Volume 2 (Chestnut CD-ROM).ISO / dir24 / aprs60.zip / DIGIS.TXT < prev    next >
Text File  |  1994-07-30  |  15KB  |  237 lines

  1.               AUTOMATIC PACKET REPORTING SYSTEM DIGIPEATERS
  2.  
  3.      To satisfy the objective of instantaneous response, APRS stations are
  4. designed to begin operating without any prior knowledge of the network.  For
  5. this reason, all APRS stations are initialized with the digi alias of RELAY
  6. and to send all UI frames via the path of RELAY.  With this form of generic
  7. alias callsign (RELAY) and wildcard digipeating (RELAY), a mobile, or new
  8. station on the air does not have to know anything about the network in advance,
  9. but to simply turn on his computer to be seen by adjacent nodes.  After 10
  10. minutes and his map begins to show the location of all stations and digipeaters
  11. on frequency, he can customize his outgoing Unproto path to specific
  12. digipeaters to cover his intended area without as much QRM. 
  13.  
  14.     It is important in any APRS network to avoid using the wildcard addressing,
  15. when possible, to minimize unnecessary QRM on frequency.  The DIGIPEATER LIST
  16. command lets you see what digipeater paths other stations are using and in
  17. version 5.7b, users can store up to 13 different DIGIpeater paths.  Then they
  18. can select any given path that is optimum for their present application with a
  19. single key stroke.  This version also added range plotting for all stations
  20. that include the new format for their transmitter power, antenna height above
  21. average terain, and gain.  Users can use these plots to estimate what paths,
  22. through what stations, might be useful.
  23.  
  24.      Although digipeaters work poorly for AX.25 level 2 connections, they are
  25. ideal for APRS operation using UI frames only.  In the Washington DC area and
  26. Chesapeake Bay area, we are establishing a network of WIDE area DIGI's on the
  27. simplex packet frequency of 145.79.  This frequency is for Keyboard QSO's and
  28. all UI frame applications.  Even leaving Personal mail boxes on the frequency
  29. is welcome, since mail is posted at keyboard rates and is read off-the-air by
  30. the mailbox owner without QRM.  The normal CONNECTED operation of BBS's,
  31. mail forwarding, file transfers, TCP-IP and DX clusters are discouraged!
  32.  
  33. WILDCARD DIGIPEATING:  To make these WIDE area digipeaters respond to mobiles
  34. and new stations, all wide area digipeaters have the same alias of WIDE in
  35. addition to their normal FCC callsign.  This second generic alias of WIDE
  36. adds tremendous flexibility to APRS networks by significantly extending the
  37. ranges for wildcard digipeating using well situated permanent digipeaters.
  38. These wide area Digi's are spaced several tens of miles apart so that they
  39. are not too close, but that they can hit their adjacent other WIDE digi's.
  40. Assuming WIDE area digipeaters are about 30 to 50 miles apart it is very easy
  41. to select an UNPROTO path prior to a road trip which will assure that your
  42. location packets will always get back to your home area.  The following example
  43. shows a string of digipeaters along the east coast.  The HAM calls of SOUTH and
  44. NORTH are used for clarity.
  45.  
  46. CALL:   NORTH-3    NORTH-2    NORTH-1   HOME-0    SOUTH-1   SOUTH-2   SOUTH-3
  47. ALIAS:   WIDE       WIDE       WIDE     RELAY     WIDE      WIDE      WIDE
  48.  
  49.     If the mobile is going south for the day, and will be operating in the
  50. vicinity of SOUTH-3 digipeater, the operator can preset his UNPROTO path to be
  51. via WIDE,SOUTH-2,WIDE.  Notice that not only will his packets make it back to
  52. home from the area of SOUTH-3, but also from the area of SOUTH-1 since SOUTH-1
  53. will also respond to the first WIDE in the list.  Similarly, stations in the
  54. vicinity of SOUTH-3 are alerted to his movements as he leaves home, since the
  55. WIDE,SOUTH-2,WIDE specification is symetrical.  If he set the UNPROTO path to
  56. SOUTH-3,SOUTH-2,SOUTH-1 in the usual manner, he would not be tracked at his
  57. home until he actually arrived at his destination.  As you can see, having the
  58. flexibility to alternate the generic alias's of RELAY or WIDE with other
  59. known sites gives a good degree of flexibility without having to change the
  60. UNPROTO path while on the road.  Using the three digipeater string, he can
  61. wander up to 150 miles in his planned direction and still be tracked by the
  62. XYL.  If he has no idea where he is going, he can always use the path of
  63. WIDE,WIDE or even WIDE,WIDE,WIDE and go anywhere, but with greater QRM on the
  64. channel.  Yes there are multiple collisions, and repeats, but the packet does
  65. get out to the third tier!
  66.  
  67.  
  68. DEDICATE WIDE AREA APRS DIGIPEATER SET UP
  69.  
  70.    To set up a WIDE area APRS digi, simply connect a TNC to a radio, and put
  71. it as high as you can get it.  Set the following minimum commands:
  72.  
  73. cmd:   MY W3XYZ-x                 (the digipeater call and SSID)
  74.        MYA WIDE                   (this makes it digipeat WIDE packets)
  75.        UNPROTO APRS VIA WIDE,WIDE (so everyone sees it)
  76.        B E 60                     (Sets Beacon to once every 10 minutes)
  77.        BT !DDMM.mmN/DDDMM.mmW#Pwr5360/WIDE...(identifying comments)...
  78.             |         |      | | ||||  |_____ makes station show up green
  79.             |         |      | | ||||________ Omni (Direction of max gain)
  80.             |         |      | | |||_________ Ant gain in dB
  81.             |         |      | | ||__________ Height = log2(HAAT/10)
  82.            LAT      LONG     | | |___________ Power = SQR(P)
  83.                              | |_____________ Power-Height-Gain PHG indicator
  84.                              |_______________ # is symbol for digipeater
  85.  
  86. As you can see by the integers in the Pwr string, there are only 9 plus 0
  87. possible values for each of these fields as follows:
  88.  
  89.   DIGITS   0  1  2   3   4   5   6    7    8    9  as used in the Pwr field
  90.   -------------------------------------------------------------------------
  91.   POWER    0, 1, 4,  9, 16, 25, 36,  49,  64,  81  watts  SQR(P)
  92.   HEIGHT  10,20,40, 80,160,320,640,1280,2560,5120  feet   LOG2(H/10)
  93.   GAIN     0, 1, 2,  3,  4,  5,  6,   7,   8,   9  dB
  94.   DIR      0,45,90,135,180,225,270, 315, 360,   .  deg    D/45  This offsets
  95.                                                    the range circle in the
  96.                                                    indicated direction
  97.                                                  
  98. NOTE ABOUT POWER LEVELS:  There is little justification for making a WIDE
  99. area digi run any more power than an average mobile rig.  The function of the
  100. WIDE digipeater is to pick up signals from mobiles and to relay those posits
  101. to fixed stations.  The mobile is usually at ground level and is using an
  102. omni directional whip.  If his path gets him into the digipeater, then he
  103. should be able to hear it.  Home stations, however, usually run higher
  104. antennas and will easily be able to hear the digipeater.  Both WIDE area
  105. APRS digipeaters that I have installed use only 1 and 5 watt radios.  Running
  106. real high power just adds QRM beyond the effective range of the repeater.
  107. If you are concerned about linking to the next WIDE, forget it.  If your digi
  108. can hear it, then it should be able to hit it with 10 watts!
  109.  
  110.  
  111. PREMPTIVE DIGIPEATING:   The ultimate APRS digipeater configuration is to have
  112. modified TNC-2 digipeater code so that any digipeater hearing a UI frame with
  113. its callsign anywhere in the UNPROTO path will pause for a reasonable time and
  114. then digipeat the packet as long as it was not previously digipeated by any
  115. stations earlier in the list.  This way, to always report your movements back
  116. home, you always place digipeaters in your UNPROTO command in the reverse
  117. order of your travels.  Your packets will be digipeated back to your home area
  118. as you enter each new digipeater in your direction of travel.  For example, if
  119. you live in the vicinity of DIGI-1 below and routinely travel in the direction
  120. out to and including DIGI-3.
  121.  
  122.  
  123.      DIGI-1    DIGI-2    DIGI-3    etc
  124.  
  125.      If we can get TAPR to modify the code, the mobile could specify the
  126. UNPROTO path of VIA DIGI-3,DIGI-2,DIGI-1 in order to be tracked anywhere all
  127. the way out to the area of DIGI-3.  If only DIGI-1 hears the packet, it will
  128. pre-emptively digipeat the packet and set its digipeat flag.  If DIGI-2 also
  129. hears the original packet, DIGI-2 will pause for P seconds to see if DIGI-1
  130. repeats it.  If so, it does nothing, since DIGI-1 follows it in the list.  If
  131. not, after P seconds, it digipeats the packet for DIGI-1 to subsequently
  132. further digipeat in the normal manner.  Similarly, DIGI-3 pauses for 2*P
  133. seconds to see if DIGI-2 digipeated the UI frame.  If so, it does nothing.  If
  134. not, after the 2*P seconds, it digipeats the packet.  Even if the packet pauses
  135. and comparisons are not performed, (to simplify the code) the worst case is that
  136. N duplicates will arrive at the destination for all N digipeaters that
  137. simultaneously heard the original UI frame.  Since these are UI frames, any
  138. pauses in the network for the comparisons suggested, are not significant.  The
  139. extra code to do the pauses and comparisions only protects against duplicates
  140. when two digipeaters hear the same original packet, and might not be worth the
  141. extra code.
  142.  
  143.      This algorithm works perfectly well in reverse.  If a mobile desires to
  144. announce his progress forward in the direction of his travel he can specify
  145. the digipeaters in the forward direction.  Then using this algorithm, all of
  146. his packets will be repeated in the forward direction, no matter where he is
  147. along his route, but not in the backward direction.
  148.  
  149.      Until we get new UI forwarding algorithms in standard TNC's, however,
  150. the general aliases of WIDE and RELAY will do nicely.  If fixed, known
  151. digipeaters are available, even with the generic alias of WIDE, it is best
  152. for fixed APRS stations to use the digipeaters unique callsign instead of
  153. alias to avoid any ambiguity.  Also avoiding the wildcard addresses except
  154. when necessary, significantly reduces QRM on the channel.
  155.  
  156.      APRS now has a special command SETUP-WIDE that sets ones own station to
  157. the ALIAS of WIDE vice RELAY.  This is so that an APRS station that is well
  158. situated, can serve as a WIDE digipeater.  This special command is used to
  159. override the automatic TNC initialization routine that always sets APRS TNC's
  160. to the generic alias of RELAY.  This command should be used with caution and
  161. with the understanding of all stations on the net.  Too many WIDE's and too
  162. close together causes too much QRM.  The command has to be used each time APRS
  163. is run, since the initialization routine will always reset your alias to RELAY.
  164. Also, if you use the Shift-F1 command, your symbol will be set as a digipeater
  165. and the word WIDE will be installed in your POSIT comment field so that your
  166. station will show up on all screens in green.  This color (showing you as
  167. WIDE) will be lost, however, if you have a weather station hooked up to COM2,
  168. since it re-writes the POSIT string every few minutes.
  169.  
  170.  
  171.  
  172. TheNET CONSIDERATIONS:  I now understand that G8BPQ TheNET code for the
  173. DataEngine includes a DIGIon command that if set to 255 will permit
  174. Digipeating of UI frames only.  Hopefully, other TheNET writers will include
  175. a UI frame only digipeat command.  The problem, however, is that since the
  176. digipeat ALIAS is the same as the NODE alias, you cannot operate more than
  177. one NODE with the ALIAS of WIDE or it will totally screw up the NODE
  178. functions.  We are asking NODES to consider permitting another ALIAS for UI
  179. frames only that is not tied to any of the node functions.
  180.  
  181.      Since NODES are so much smarter than digipeating, the ultimate solution
  182. is to have the NODES do all UI frame routing.  The APRS station simply sends
  183. his UI frame TO APRS VIA HOME;  Any NODE hearing that transmission that has
  184. knowledge of the route to HOME, will send the single packet via the NODE
  185. network (internode, level 4) to the HOME node!  When it arrives at the HOME
  186. node, it is transmitted once as a UI frame.  With this arrangement, a mobile
  187. only has to specify his one intended destination, no matter where he travels!
  188.  
  189. DIGI/NODE COMPATIBILITY:  Since the user should not have to change his digi
  190. path as he drives from one area to another, he should be able to specify a
  191. path that is compatible with both nodes and digipeaters.  This is easily
  192. accomplished by assuming that the LAST field in an UNPROTO digi list is the
  193. HOME NODE and should be the ultimate destination for the UI frame through any
  194. level 4 network.  Any and all preceeding fields are assumed to be DIGI's only.
  195. With this arrangement, the user could use an UNPROTO path of APRS VIA WIDE,
  196. HOME so that any generic WIDE digipeaters would repeat his position to their
  197. local area as would any WIDE NODES in the usual digi fashion.  Only the
  198. node that hears the direct packet would also forward it through the network
  199. at level 4 to the HOME NODE.  If only one field is included in the digipeater
  200. string, it would be interpreted as both a digi and a HOME destination without
  201. any difficulty.  Digi's and NODEs would digipeat it, and nodes (hearing it
  202. direct) would forward it at level-4.  It is important that NODES hearing
  203. digipeated UI frames from other digis do NOT enter the packet into the network,
  204. to eliminate duplication.  Only the ones hearing the direct signal should
  205. be repsonsible for doing the level 4 routing..
  206.  
  207. EXAMPLE:  A typical mobile just wanting to keep his spouse informed of his
  208. whereabouts might want to just use the UNPROTO path of APRS VIA HOME.  Then
  209. his UI frames will be digipeated by the local HOME node or digi and will
  210. also be routed back to HOME by all NET-NODES along his travels.  If he also
  211. wants to be seen by most HAMS in the areas of his travels, then he sets
  212. his path to APRS VIA WIDE,HOME.  If he travels through a region that has
  213. both DIGIs and NODES, he might choose APRS VIA WIDE,WIDE,HOME.  This way any
  214. areas with digis would digipeat via WIDE,WIDE and if he gets to an area with
  215. nodes which are aware of the path to HOME, then they will forward his packet
  216. there.
  217.  
  218.      Finally, since I hope to build a regional area Tracking network, the node
  219. should also permit the SYSOP to turn off other level 4 routing if he wants to
  220. make a dedicated network of APRS nodes just for tracking.  Such a network would
  221. be swamped if all of the BBS and other CONNECTED protocol users began to use
  222. it, and the original purpose of the network would be defeated.
  223.  
  224.    Still, most of these APRS support ideas could be included in all NODES so
  225. that a minimum of APRS tracking could be supported by ALL networks on all
  226. frequencies, especially where there is not yet a dedicated APRS TRACKING
  227. NETWORK.  I think there are other undeveloped applications for shipping UI
  228. frames through ALL networks which have not yet been explored.  The capability
  229. should be there, in any case, so that experimentation can proceed.  Time will
  230. tell.  These few paragraphs were primarily written to the NODE CODE writers
  231. such as John G8BPQ and Mr. Roberts of X1-J.  But are included here in general
  232. distribution for all to read.
  233.  
  234.  
  235. SEE README.HF for setting up your UNPROTO path for HF and HF/VHF gateways..
  236.  
  237.